(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
28 March 2002 (28.03.2002) 




PCT 



lllilllliliilllllllllllll 



(10) International Publication Number 

wo 02/25879 Al 



(51) International Patent Classification^: H04L 12/56 (81) Designated States (national): AE, AG, AL. AM. AT, AU, 



(21) International Application Number: PCT/SEO 1/01 681 

(22) International Filing Date: 26 July 2001 (26.07.2001) 
(25) Filing Language; English 



(26) Publication Language: 



(30) Priority Data: 

09/666,529 20 September 2000 (20.09.2000) US 

(71) Applicant: TELEFONAKTIEBOLAGET LM ERICS- 
SON (pubO [SE/SE]; S-126 25 Stockholm (SE). 

(72) Inventors: 1V1IKL6s, GySrgy; Eizsebet u.29.fszl.l, 
H-1037 Budapest (HU). FELEGYHAZl, Mirk; Bol- 
garkertesz u. 23. szt 1. H-1 148 Budapest (HU). 

(74) Agent: GULLSTRAND, Malin; Ericsson Radio Systems 
AB, Patent Unit Research, S- 164 80 Stockholm (SE). 



AZ, BA, BB, BG. BR, BY, BZ, CA, CH. CN, CO. CR, CU, 
CZ, DE, DK, DM, DZ, EC, EE, ES, H, GB, GD, GE, GH, 
CM, HR, HU, ID, a, IN, IS, JP. KE, KG, KP, KR, KZ, LC, 
LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, 
MX, MZ. NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, 
SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW. 



English (84) Designated States (regional): ARIPO patent (GH, GM. 

KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, 
TG). 



Published: 

— with international search report 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



(54) Title: TRAFFIC DEPENDENT BLUETOOTH SCATTERNET OPTIMIZATION PROCEDURE 



DATA STRUCTURES 



TRAFFIC FORWARDING 
TABLE 



NEIGHBOR TRAFFIC 
TABLE 



00 

r5 




PROCEDURES 



LINK SETUP 



LINK M-S SWITCH 



UNKTEARDOWN 



MESSAGES 




LinkSetupSolicil 



LinkSetupReq 



LinkSetupAck 




LinkMSSwitchReq 



LinkMSSwilchAck 



LinkTeardownReq 



LinkTeardownAck 



(57) Abstract: Network reconfiguration is accomplished by dynamically reconfiguring a network. Decisions whether to initiate 
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TRAFFIC DEPENDENT BLUETOOTH SCAITERNET OFIIMIZATION 

PROCEDURE 
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BACKGROUND 

The present invention relates to ad-hoc networks. More particularly the 
present invention relates to network optimization in ad-hoc networks. 

Conventional networking protocols are based on the characteristics and/or 
features of networks with fixed infrastructures. In networks with fixed 
mfrastructures. the arrangement of the links between network nodes .ypic^y does 
not change. The disadvantage is that networks with fixed infrastructures cannot be 
easily reconfigured to account for increases in data traffic, also caUed system 
loadmg. Accordingly, when system loading increases for one node the 
surrounding nodes are likely to experience increased delays in the tran^nission and 
reception of data. 

m contrast to networks with fixed infrastructures ad-hoc networks do not 
have a fixed infrastructures. Accordingly, nodes in ad-hoc networks act as both 
hosts and routers. An ad-hoc network is formed when a number of nodes decide 
tojointogethertoformanetwork. Bluetooth is an ex^nplary ad-hoc networking 
technology. Bluetooth is an open specification for wireless communication of both 
voice and data. It is based on a short-range, universal radio link, and it provides a 
mechanism to form smaD ad-hoc groupings of connected devices, without a fixed 
network infrastructure. Bluetooth devices can include devices such as printers 
PDAs, desktop computers. FAX machines, keyboards, joysticks, telephones or 
virtuaUy any device. Bluetooth operates in the unHcenced 2.4 GHz Industrial- 
Scientific-Medical (ISM) band. 

Figure 1 illustrates a Bluetooth piconet. A piconet is a collection of digital 
devices, such as any of those mentioned above, comiected using a single Bluetooth 
frequency hopping chamiel. A piconet is iniUally formed with two comiected 
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devices, herein referred to as Bluetooth nodes. A piconet can include up to eight 
active Bluetooth nodes. In each piconet, for example piconet 100, there exists one 
master Bluetooth node and one or more slave Bluetooth nodes. In figure 1 
Bluetooth node 101 is the master node and node 102 is a Bluetooth slave node. 
5 According to the Bluetooth standard a slave node can directly communicate 

only with the master node. However, it is assumed that Bluetooth can be 
implemented such that two slave nodes can communicate through the master node. 
Figure 2 illustrates a piconet with a master node 201 and a plurality of slave nodes 
202-208 arranged m a star network topology. If slave node 202 wishes to 

10 communicate with slave node 206, slave node 202 would have to transmit the 

information it wished to communicate to the master node 201. Master node 201 
would then transmit the information to slave node 206. 

A scattemet is formed by multiple independent and unsynchronized 
piconets. Figure 3 illustrates an exemplary scattemet 300. In figure 3, piconet 1 

IS includes the miaster node 303 and the slave nodes 301, 302 and 304; piconet 2 
includes the master node 305 and the slave nodes 304, 306 and 307; piconet 3 
mcludes the master node 309 and the slave nodes 308, 310 and 311; and piconet 4 
includes master node 310 and slave node 312. As illustrated m figure 3, node 310 
acts as both a slave node in piconet 3 and as the master node of piconet 4. To 

20 implement a scattemet it is necessary to use nodes which are members of more 
than one piconet. Such nodes are herem referred to as bridge nodes. If, for 
example, node 301 wishes to communicate with node 312, then nodes 304, 308 
and 310 act as bridge nodes by bridging the connection between the three piconets 
and in particular between nodes 301 and 312. For example, node 301 transfers 

25 the mformation to die master node of piconet 1 node 303. Master node 303 

transmits the mformation to bridge node 304. Bridge node 304 then forwards the 
information to master node 305, which in tum, transmits the information to bridge 
node 308. Bridge node 308 forwards the mformation to master node 309 which 
transmits the information to bridge node 310, which in turn, forwards the 
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infonnation to destination node 312. 

Due to the Bluetooth protocol, a Bluetooth unit can transmit or receive in 
only one piconet at a time. Accordingly, a bridging Bluetooth unit must switch 
between piconets on a time division basis. Since the bridging unit must 
synchronize its radio from one piconet to another and perform the necessary 
signaling, the throughput of the piconet is reduced due to the amount of time 
required to switch between piconets and due to the associated control signaling. 

Although it is assumed that scattemet forming can be performed through 
the use of nodes participating in more than one piconet at a time as described 
above, the current Bluetooth specification does not define methods for selecting 
which links to semp and how to choose master and slave roles. As a consequence, 
a very large number of scattemet configurations are possftle for a given set of 
nodes. While many different scattemets may provide comiectivity for a given set 
of nodes, their performance in terms of achievable throughput and delay are 
largely different. This is because different scattemet configurations can differ in 
the number of hops between nodes, the amount of overhead due to bridging 
between piconets, and the actual traffic mix in each piconet. However, there are 
no known methods for using a single scattemet to optimize its own configuration. 

SUMMARY 

These and other problems, drawbacks and limitations of conventional 
techniques are overcome according to the present mvention by a method and 
apparatus which dynamically reconfigures a network. In accordance with 
exemplary embodiments of the present invention the methods and apparatus are 
distributed in each node in the network, wherein each node determines based upon 
25 information stored in the node whether to initiate reconfiguration of the network. 

In accordance with one aspect of the present invention it is determined 
whether a predetermined time period has expired. If the predetermined time 
period has expired a table is examined. A link setup procedure, a role switch 
procedure or a link teardown procedure based upon information in the first or 
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second table is selectively initiated. The link setup procedure is initiated by a 
node which forwards traffic between two end nodes, and the role switch procedure 
and the link teardown procedure are initiated by an end node. 

In accordance with another aspect of the present invention a network 
5 includes a first node including a first table and a second node including a second 
table. A first communications link connects the first node and the second node. 
The first node and the second node periodically determine whether to initiate 
reconfiguration of the network based upon information stored in the first and 
second tables. The first table contains information about traffic that the first node 
10 is forwarding and information about traffic to and firom nodes which are neighbors 
of the first node, and the second table contains information about traffic that the 
second node is forwarding and information about traffic to and fi:om nodes which 
are neighbors of the second node. 



BRIEF DESCRIPTION OF THE DRAWINGS 

15 The objects and advantages of the invention will be understood by reading 

the following detailed description in conjunction with the drawings in which: 

FIG. 1 illustrates an exemplary piconet; 

FIG. 2 illustrates an exemplary star-topology network; 

FIG. 3 illustrates an exemplary scattemet formed by a plurality of 
20 piconets; 

FIG. 4 illustrates logical elements ia a node in accordance with exemplary 
embodiments of the present invention; 

FIGs. 5A and 5B respectively illustrate an exemplary Traffic Forwarding 
Table and an exemplary Neighbor Traffic Table in accordance with the present 
25 invention; 

FIGs. 6A and 6B illustrate a plurality of nodes which exchange messages 
durmg Lmk Setup in accordance with the present invention; 

FIG. 7A illustrates an exemplary method for initiatmg Link Setup in 
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accordance with the present invention; 

HGs. 7B and 7C illustrates an exemplary method for performing Link 
Setup m accordance with the present mvention; 

FIGs. 8A^C illustrate exemplary messages used for Link Setup m 
accordance with the present invention; 

HGs. 9A and 9B illustrate a plurality of nodes perfonning a Master-Slave 
Switch m accordance with exemplary embodiments of the present mvention; 

FIG. 10 illustrates an exemplary method for the mitiation of the Master- 
Slave Switch m accordance with the present mvention; 

FIG. 11 illustrates an exemplary method for perfonning the Master-Slave 
Switch m accordance with the present mvention; 

FIGs. 12A and 12B illustrate exemplary messages for the Master-Slave 
Switch m accordance with the present mvention; 

FIGs. 13A and 13B illustrate a plurality of nodes performmg a Link 
Teardown m accordance with exemplary anbodhnents of the present invention; 

HG. 14 ilhistrates an exemplary method for the initiation of Lmk 
Teardown m accordance with the present invention; 

HG. 15 illustrates an exemplary method for performmg Lmk Teardown in 
accordance with the present mvention; 

HGs. 16A and 16B illustrate exemplary messages exchanged during Link 
Teardown m accordance witii the present invention; and 

FIGS. 17-19 mustrate a plurality of nodes reconfiguring their comrections 
usmg Lmk Setup. Master-Slave Switch and/or Link Teardown m accordance witii 
exemplary embodiments of the present mvention. 

DETAILED DESCRIPTION 

The present mvention is directed to optimization of network configuration 
In general, the present mvention accomplishes this by dynamically assignmg 
master and slave roles, and by dynamicaUy setting up and tearing down Imks 
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between nodes. In so doing, a network topology is dynamically reconfigured 
based upon the current traffic requirements of the network. 

In the foUowing, the present invention is described as a technique for use 
in a Bluetooth scattemet. However, one skilled in the art will recognize that the 
5 present invention is applicable to other types of wireless or wireline networks. 

Figure 4 illustrates the logical elements in each node m accordance with 
the present invention. The logical elements can be broken down into data 
structures, procedures and messages. Each node in the scattemet maintains a 
Traffic Forwarding Table and a Neighbor Traffic Table data structure. As will be 

10 described in more detail below, each node will periodically scan its Neighbor 

Traffic Table and Traffic Forwarding Table. Based on the information contained 
in these tables, the node will decide whether it may be beneficial for it to initiate a 
reconfiguration attempt. Link Setup procedmres will be initiated by a node 
forwarding traffic between two other nodes, while Link Teardown and Lmk 

15 Master-Slave Switch procedures are initiated by one of the end nodes of a 
particular link. 

As indicated by the Imks between the Traffic Forwarding Table data 
structure and the Link Setup procedure m figure 4, the Traffic Forwaxdiog Table 
will be used by a particular node during the Link Setup procedure. Furthermore, 

20 as indicated by links between the Link Setup procedure and the LinkSetupSolicit, 
LinkSetupReq and LinkSetupAck messages, these messages are used during the 
Link Setup procedure. Moreover, as indicated by the links between the Neighbor 
Traffic Table data structure and Lmk Setup, Link Master-Slave Switch and Link 
Teardown procedures, the Neighbor Traffic Table will be used for these 

25 procedures. As also indicated by the links between the Link M/S switch 

procedure and the Link M/S switch request and LinkMSSwitchAck messages, 
these messages are used during the link M/S switch procedure. Finally, as 
mdicated by the link between the LmkTeardown procedure, the LinkTeardownReq 
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LinkTeardown procedure. 

FiSwe 5A im^^es an exemplary -Raffle Forwarttog Table i. ac»,da„ce 
™'b mc pesem j,,^, ^^^^^^ ^^^^ ^ 

"ga^g pact* aa, are forwarded by le parHcular node. i.e.. „afflc to, 
^ne^ ~ - .0 d.e parUcCar node. Ti« fa enta^ 

aeTrafficFarwa«in^Tab.e, -Be^eeo-, indicate. Repair., nodes for wbid, 
fl«,^arnodeisforwarding,nepaeto.. r>.s^„^^^^^ 

Traffic . contain, a n>ea.„emen, Of ae an«n, Of ttafBe i. fo,™^ 
aeparacuiarnodeforeachpairofncdes. llen^a^^of^.^^, 
.raffle eonained in d,e second col™ of d„ r«r^ Table is an 

average Measnremea over a predaenmnedmeasnr^nen. period. TledOrd 
colu.^ Of .be Traffic R^XaMe. TV. Mca.es *e «n« when ,be las, 
Ln^^psolici,n^sagewassen..andfl«fonrd,cobnnn. -B^. represents 
B^,sa,»ctoffc<»n«ernsedforse.ting„paUnkbetween 

Fignre 5B ianatrates .he Neighbor IVafBc Table. V. Neighbor Traffic 
Table con.anu, tofonnaflon regarding the neighbor nodes (both cn™,, and 

previousneighb™)andtheam„™,oftrafflc,„andfton,ea^.eighbor. Tt. 
^cy Of Neighbor Table. To Node-, indicates each neighbor of d. 

Ode. i.e.. note tha, are direcdy connected by a Bluetooth in* In 
a^oo. nodea that are no, c»n«,M to the particute ^, ^ ^ 

w*n rad.0 range o„he parUcular node, or even odter nodes d., are not widnn' 

range o,«.e pamcnlar node, can also be inCnded b tb. Neighbor ^affic 
T*le Tle«c„ndcolu„„oftbeNeighborTrafflcTabie. "Role-. hKiicates the 
ro^e Of the neighbor node, wherein an M indica^, a ^ ^ j 
u^cates a siave node role, m or OUT indicates whether the par^ar node is 
«am range or out of radio range, and Unknown h^ fl« « i, ^„ 

whetheranodeis„idnn»witho«of.her«Bo,ange„fd,epardcularnode He 
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third column of the Neighbor Traffic Table, "Traffic", provides the total 
measured traffic on the given link in both directions. The total measured traffic is 
an average value over a predetermined measurement period. The fourth column 
of the Neighbor Traffic Table, "T^^\ provides Ae time when this link was 
5 setup. The fifth column, "T^^^^"" , mdicates the time at which the link between 
the particular node and the neighbor node was torn down. The sixth column, 
"Bteardovm''* 2L backoff timer for the tearing down of a link between the particular 
node and the neighbor node. The seventh column, TMSswiich> provides a time when 
the last Master-Slave Switch initiations were sent between the particular node and 

10 the neighbor node. The eighth column of the Neighbor Traffic Table, "B^sswitch"* 
is a backoff counter for the Master-Slave Switch. 

Figures 6A and 6B illustrate a plurality of nodes which are performing a 
Link Setup in accordance with exemplary embodiments of the present invention. 
The arrows illustrated in figures 6A and 6B mdicate regular traffic flow between 

15 the nodes and not necessarily the messages used for the LinkSetup procedures. 

Figure 6A illustrates that initially node A sends traffic which is destined for node 
B through node C. Node C, the forwarding node, would initiate a LinkSetup 
procedure and solicits nodes A and B to setup a direct link between the two nodes. 
Accordingly, as illustrated m Figure 6B, after the link between nodes A and B are 
20 setup, nodes A and B can directly exchange information between the two nodes 
without sending the information through node C. Further, as illustrated by the 
half-light, half-dark circle of node A, node A now is the master node of the 
piconet comprising nodes A and B and a slave node in the piconet comprising 
nodes A, B and C. 

25 Figure 7 A illustrates an exemplary method for determming whether a node 

should initiate a Link Setup procedure- Link reconfiguration initiation decisions 
are made periodically at each node at the expiration of a time period of 
This time period will not be equal at all nodes, but mstead it will be chosen 
randomly between T^^ and T,,^, The difference between T^^j„ and 
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"^checkmax detennines the amount of randomization that will be allowed when 
selecting 7^^^. It win be recognized that increasing the values of T^^^ and 
Tchedomx decreases the amount of computational and communicaUons overhead 
imposed on nodes and inq)roves the accuracy of traffic measurements and 
therefore makes reconfiguration attempt decisions more accurate. However, 
increasing these values may slow down the reconfiguration process. Accordingly, 
once a node, e.g., node C. determines wheflier the time period has expired, 
the node determines wheflier to initiate a Link Setup procedure based upon the 
information stored in die Traffic Forwarding Table. Using the Traffic 
Forwarding Table, node C examines each row to determine wheflier flie traffic for 
fliatrowislessflmTraff^^. Traff^^ is flie minimum amount of forwarded 
traffic tiiat triggers Link Setup. For each row where traffic is less flian Traff . 
«^ node C sets flie backoff counter, equal to 1 (Step 703). Node C tiien 
selects all nodes in flie Traffic Forwarding Table which have not had a Link Setap 
initiation for at least P^*B^ (Step 706). P^, is a thne period which is half 
flie minimum time period between two Link Setap initiation attempts. Next node 
C determines wheflier at least one node was selected from the Traffic Forwarding 
Table (Step 709). If no nodes were selected from flie Traffic Forwarding Table 
("No" pafli out of decision Step 709), flien flie processing for node C ends (Step 
20 712). 

If at least one node from flie Traffic Forwarding Table was selected ("Yes" 
pafli out of decision Step 709), tiien node C selects flie row R mfh flie highest 
traffic in die Traffic Forwarding Table out of ttie selected nodes {Step 715). Next 
node C determines wheflier flie traffic in flie row R is less flian Traff^ (Step 
718). If node C determines that flie traffic in flie selected row is less flian 
TrafU«»p ("Yes" pafli out of decision Step 718) flien flie processing for flie node 
ends (Step 712). If. however, flie traffic in flie selected row is not less flian 
TrafU«o, ("No" pafli out of decision Step 718) flien node C updates T.^^ to flie 
current time t (721). Next node C sets flie backoff counter B_ to a mILum 
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value of 2*B^ and B^eiupmax (Step 724) and sends a LinkSetupSolicit message to 
any of the nodes betwera which traffic in flie selected row R is forwarded (Step 
727). The backoff timer B^^^^ is set to I'^B^ to reduce the frequency that a node 
initiates a Link Setup, while setting an upper Innit of B^^p^ prevents the backoff 
5 timer from mcreasing to a very high value where Link Setup is initiated too 
infrequently. 

Figure 7B illustrates an exemplary method for a node which has received a 
LinkSetupSolicit message. Initially, a node, e.g., node A, receives a 
LinkSetupSolicit message from C (Step 730). Figure 8A illustrates the 

10 LinkSetupSolicit message which includes a From field, a To field, a Between field 
and a WinNet field. The From field indicates the node which is sending the 
LinkSetupSolicit message, the To field indicates the node which is to receive the 
LinkSetupSolicit message, the Between field mdicates the two end points of flie 
new link and the WinNet field indicates the amount of capacity in kilobits per 

15 second (kbps) that is e3q)ected to be freed at the forwarding node as a result of 
rerouting the forwarded traffic to the new link. 

Node A then determines whether a time period of at least P^^^ has passed 
since the last link was torn down (Step 733), The time period P^^^ is a constant 
value and is selected such that nodes which have recently been setup are not torn 

20 down. It will be recognized that mcreasing the value of P^^^ slows the 

reconfiguration process but decreases the risk of unnecessarily setting up a new 
link that will be torn down soon afterwards. If the node determines that P^j^ has 
not passed ("No" path out of decision Step 733) then the Link Setup procedure 
fails (Step 736). If, however, the time period P^ has passed ("Yes" path out of 

25 decision Step 710) then node A determines the amount of capacity increase 

WmMaster(A) and WinSlave(A) if the requested link were built (Step 739). It 
wiU be recognized that the increase in capacity is equal to the negative of the 
increase in the overhead. If both WinNet + WinSlave(A) and WmNet + 
WinMaster(A) are less than zero ("Yes" path out of decision Step 742) then the 
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procedure fails (Step 736). If WinNet + WinSlave(A) and WinNet + 

WudSla^er(A)are not bothless than zero ("No-path out Of decision Step 742) 
tt^B node A sends a LinlcSetupReq message to the other end Of ^ 
WinMaster(A) and WinSIave(A) (Step 745). 

Hgure 8B iBustrates the LinkSetupReq message which includes a From 
fidd. a To field, a Traif field, an M/S field, a WinNet field, a WinMaster field 

andaWinSlave field. The From field indicates the node Which is sendmg the 
LmkSetupReq message, the To field mdicates the link which is to receive the 
LmlcSetupReq message and the Traff field is the amount of current trafiic activity 
for the source node including both incoming and outgoing trafiic. T,e M/S field 
^d.cates Whether the node whichissendh^gd^eLink^^^^^ 
or not, the WmNet field is the amount of capacity that the forwarding node is 
^pected to gain as a result of setting up the link, the WmMaster field and the 
WmSlave field are the amount Of capadtythatthesourceis expected t^^ 
result Of settmg up the link When the source node acts as the master oraslave 
^dc respecfively. Acco„lh,gly, h, the example described above in connection 
w^th figure 7B.nodeAwouldplaceWinMaster(A) in the WinMa^ 
WiiiSbve(A) in the WinSlave field. 

Figure 7C iUu^mes m e».^ „eU,«, for a „„de wUch receive, a 
U-I^Se^ n^ssage. A node, e.g.. n«ie B. receives Linl.Se^,Re<, 
message (S^, 748) and calculates Wia]^as..r(B) and WiaS,ave(B) (S,ep 751, 
Neanode B calcuh.es gain M, whicb is e,ua. ,o WiuNe. + Wini^as«r(B) + 
W«,SIave(A) «a gain S, wliich is equal » WiuNee + WiuMas,er<A) + 
WinSlavetB, (S.ep 754). >f gain M and gain S are boh greater U»n 0 CYes- pa«, 
ou. of decision step 757, .hen node B seleas tager .,a.e gains h.««n gain 
Mandga.SandsendsaLin,=Se,upActn»ssage»„odeA(Step7«„. IfgainM 

. .arger tta. Gain S d« nc^e B ac as ae master node aad i, Gain S is Jger 
Am Gam M node B acts as a slave node. 

Figure 8C illustrates tte LtokSempAdt ntessage which inctodes a Prom 
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field, a To field, an M/S field and an Info field. The From field indicates the 
node which is sending the Link Setup acknowledge message, the To field indicates 
the destmation of the Link Setup acknowledge message, the M/S field indicates 
whether the node which is sending the Link Setup acknowledge message will 
5 become the master or slave of the new link and the Info field can contain 

additional information which may be used in the actual Link Setup process, e.g. , 
page timing information. 

If gain M and gain S are not both greater than 0 ("No" path out of decision 
step 757) then node B determines whether gain M is greater than 0 (Step 763). If 

10 gain M is greater than 0 ("Yes" path out of decision step 763) then node B sends 
accepts the setup request with node B actmg as the master node by sending a 
LinkSetupAck message (Step 766). If the gain M is not greater than zero ("No" 
path out of decision step 763) node B determines whether the gain S is greater 
than zpro (Step 769). If the gain S is greater than zero ("Yes" path out of decision 

15 Step 769) then node B accepts the setup request with node B acting as a slave node 
by sending a LinkSetupAck message (Step 772). If, however, the gain S is not 
greater flian zero ("No" path out of decision Step 769) then node B will refuse the 
request (Step 775). Node B refuses the request by not responding to node A with 
an acknowledgment message. Accordmgly , the load on the network will not be 

20 increased when requests to setup links are refused. 

The procedure described above in connection with figure 7A-7C begins 
with the solicitation of a new link between the two nodes that create the highest 
amount of forwarded traffic. If this procedure is successful, the trafBc 
measurement will drop below the threshold Traff^„ setup before the new check 

25 2*P3etup time later. In addition, an exponential backoff scheme is used for sending 
solicitation messages in order to avoid a high load of these control messages. The 
exponential backoff scheme is implemented such that the backoff counter is 
multiplied by two each Link Setup attempt, and hence, unsuccessful Link Setup 
attempts are repeated with half the fi*equency of the previous Link Setup attempt. 
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Father, although the procedure described above in connection with figure 7 
illustrates selectmg the larger of the Gain M and Gain S, the procedure can also be 
implemented where if one of the nodes is already the master and the other node is 
not then the master node wiU also be the master of the new link. If neither of the 
nodes is the master or both of them are. then the node with the highest traffic 
activity will be the master of the new link. 

Figures 9A and 9B illustrate a plurality of nodes before and after a Master- 
Slave Switch. The arrows illustrated in figures 9A and 9B indicate regular traffic 
flow between the nodes and not necessarily the messages used for the Master- 
Slave Switch procedures. Accordingly, as illustrated in Figure 9A. node A is the 
master of the piconet comprising nodes A and B. and node A is a slave in the 
Piconet comprising nodes A. B and C. Since node A is exchanging information 
with node B and since node A is both the master of one piconet and a slave of 
another piconet. node A must divide its time between the piconet comprising 
nodes A and B and the piconet comprising nodes A, B and C. Accordingly, node 
A determines that it is more beneficial for it to play the master role in the link 
between nodes A and B. As iUustrated in Figure 9B. after the Master-Slave 
Switch is performed between nodes A and C, node A has now become the master 
of the piconet comprising nodes A. B and C. Furflier. node C is a slave in the 
piconet comprising nodes A and C and the master of the piconet comprising nodes 
B and C. By playing the master role in both links node A can increase its 
throughput of information being transmitted to node B because node A does not 
have to switch to participate in the piconet comprising nodes A. B and C. 

Figure 10 illustrates an exemplary method for mitiating a Master-Slave 
Switch. As discussed above. Master-Slave Switches are only initiated by end 
nodes. i.e.. either a source or destination node, and are based upon information 
contained in one of the end node's Neighbor Traffic Table. If. an end node e g 
node A. determines that a time period T^ has expired the node then detennines' 
whether it is a member of only one piconet (Step 1010). If node A is a member of 
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only one piconet ("Yes" path out of decision Step 1010) then the Master-Slave 
Switch procedure for node A ends (Step 1020) • If, however, node A is a member 
of more than one piconet ("No" path out of decision Step 1010) then node A 
selects all nodes in the Neighbor Traffic Table which have not had a Link Setup 
5 initiation attempt for at least the time period of PMsswhch * B^sswitch (Step 1025). 
PMsswitch ^ tibie minimum time period between Master-Slave Switch initiation 
attempts. 

Next, node A determines whether at least one node was selected (Step 
1030). If no nodes were selected ("No" path out of decision step 1030) then 

10 processing for node A ends (Step 1020). If, however, at least one node was 

selected ("Yes" path out of decision step 1030) then node A selects the row R with 
the highest traffic in the neighbor traffic table out of the selected nodes (Step 
1035), Next, node A determines whether the traffic m the row R is equal to zero 
(Step 1040). If the traffic in the row 2? is equal to zero ("Yes" path out of 

15 decision Step 1040) then the Master-Slave Switch procedure ends for node A (Step 
1020). 

If the traffic in the row R is not equal to zero ("No" path out of decision 
Step 1040) then node A updates Tj^ss^^^ the current time t (Step 1050) and sets 
the backoff timer BMsswitch equal to a minimum value of 2*BMsswiicb and BMsswhctaiax 

20 (Step 1060). The backoff timer B^ssmtch is set to 2*BMsswitch to reduce the 

frequency that a node initiates a Master-Slave Switch, while an upper limit of 
^Msswitchinax P^eveuts the backoff timer firom increasing to a very high value where a 
Master-Slave Switch is initiated too infrequently. Next node A sends a 
LinkMSSwitchReq message to node B (Stq> 1070). Figure 12A illustrates a 

25 LinkMSSwitchReq message. The Unk MS switch request message mcludes a 
From field, a To field, a Traff field, an M/S field and a Win field. The From 
field indicates the source of the LinkMSSwitchReq message, the To field indicates 
the destination node of the LinkMSSwitchReq message, the Traff field indicates 
the amount of traffic activity on the source node, the M/S field indicates whether 
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the source node is a master node and the Win field is the amount of capacity that 
the source node expects to gain as a result of a Master-Slave Switch. 

Figure 11 illustrates an exemplaiy method for a node which receives a 
LinkMSSwitchReq message. Initially, node B receives the LinkMSSwitchReq 
message (Step 1130) and calculates Win(B) (Step 1140). Node B then determines 
whether Win(A) + Win(B) is greater than or equal to zero (Step 1 150). If node B 
determines that Win(A) + Win(B) is not greater than or equal to zero ("No" path 
out of decision Step 1150) then node B wiU refuse the switch (Step 1160). To 
refiise the switch node B does not do anything, i.e., node B does not send a 
message to node A indicating that node B is refusing the switch. By not sending a 
message, the load on the network wiU not be increased by sending messages for 
refusing Link Master-Slave Switch request. If node B determines that Win(A) + 
Win(B) is greater than or equal to zero ("Yes" path out of decision Step 1150) 
then node B determines whether Win(A) + Win(B) is equal to zero (Step 1170). 
If it is determined that Win(A) + Win(B) is not equal to zero ("No" path out of 
decision Step 1170) then node B performs the Master-Slave Switch and sends a 
LinkMSSwitchAck message to node A (Step 1180). 

Hgure 12B iUustrates a LinkMSSwitchAck message. The 
LinkMSSwitchAck message mcludes a From field, a To field and an Info field. 
The From field indicates the source node of the LinkMSSwitchAck message, the 
To field indicates the destination node of the LinkMSSwitchAck message and the 
Info field can contain optional additional information, e.g., timing information, 
used for performing the Master-Slave Switch. 

If it is determined that Win(A) + Win(B) is equal to zero ("Yes" path out 
of decision Step 1 170) then node B determines whether node A has a higher traffic 
activity than node B (Step 1190). If node B determmes that node A has a higher 
traffic activity than node B ("Yes" path out of decision Step 1190) then node B 
and node A will perform the Master-Slave Switch and node B will send a 
LinkMSSwitchAck message to node A (Step 1180). If . however, node B 
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determines that node A does not have a higher traffic activity ("No" path out of 
decision Step 1190) then node B refuses the Master-Slave Switch (Step 1 160). 

Figures 13A and 13B illustrate a plurality of nodes before and after the 
Link Teardown procedure has been performed. The arrows illustrated in figures 
5 13A and 133 indicate regular traffic flow of messages between the nodes and not 
necessarUy the messages used for the Link Teardown procedures. As illustrated 
in Figure 13A, node A is the master of the piconet comprising nodes A, B and C, 
and node C is the master of a piconet comprising nodes C and B. As illustrated in 
Figure 13B, it is determined that the link between nodes B and C should be torn 
10 down. Accordingly, the link between nodes B and C is torn down as illustrated in 
Figure 13B. 

Figure 14 illustrates an exemplary method for determining whether to 
initiate a Link Teardown procedure in accordance with the present invention. 
Link Teardown procedures are initiated by an end node based upon information in 

15 the Neighbor Traffic Table. After determining that a time period of has 

expired, the node performing tide Link Teardown initiation procedure, e.g. , node 
A, computes an estimated edacity increase (Win) and network capacity decrease 
(WinNet) for each link if torn down (Step 1410), wherem WinNet==-2*Traf and 
Traf is the traffic on the Link. Next node A selects the rows in the Neighbor 

20 Traffic Table which have links which are up for at least P^p and which have not 

had a Liak Teardown initiation attempt for at least P,^p * B,^^^^ (Step 1415). P„p 
is the minimum time period before a link may be torn down after the link has been 
setup. Next node A determines whether at least one row was selected (Step 
1420), If no row was selected ("No" path out of decision Step 1420) the 

25 processing for node A ends (step 1425). If at least one row was selected ("Yes" 
path out of decision Step 1420) then node A selects the row R with the highest 
value of Win+ WinNet out of the selected rows (Step 1430) and determines 
whether the value of Win+ WinNet is less than zero (step 1440). If it is 
determined that the value of Win + WinNet is less than zero ("Yes" path out of 
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decision Step 1440) then the processing for node A ends (Step 1425). 

If node A determines that the vahie of Win + WinNet is not less than zero 
("No" path out of decision Step 1440) then the node updates T^^^ to the current 
time t (Step 1450) and sets the backoff timer to a minimum of 2*B.^^ 
5 and B^^^ (Step 1460). Thebackoff timerB.^_is setto2*B^^tlrJuce 
the frequency that a node initiates a Link Teardown, while an upper limit of 
B|«r<townm« prevcnts the backoff timer from increasing to a very high value where a 
Link Teardown is initiated too infrequently. Next node A calculates Win(A) (Step 
1465) and sends a LinkTeardownReq message to the node with which it wishes to 
10 teardovm the link (Step 1470). 

Figure 16A illustrates an exemplary LinkTeardownReq message in 
accordance with the present invention. The LinkTeardownReq message includes a 
From field, a To field, a Trafi' field, a Win field and a WinNet field. The From 
field indicates the node sending the LinkTeardownReq message, the To field 
indicates the destination of the LinkTeardownReq message and the Traff field 
indicates the fraflic activity at Hie source node. The Win field contains an 
indication of the amount of capacity that the source node is expected to gain as a 
result of the Link Teardown and the WinNet field is the estimated negative gain in 
network capacity as a result of the Link Teardown, i.e., WinNet in this case 
20 represents the increase in overhead due to the Link Teardown. 

Figure 15 illustrates an exemplary Link Teardown procedure in accordance 
with the present invention. Initially, node B receives the LinkTeardownReq 
message (Step 1530) and calculates Win (B) and WinNet (Step 1540). Node B 
then determines whether Win(A) + Win(B) + WinNet is greater than or equal to 
zero (Step 1550). If node B determines that Win (A) + Win (B) + WinNet is not 
greater than or equal to zero ("No" path out of decision Step 1550) then node B 
refuses the LinkTeardownReq (Step 1560). In accordance with exemplary 
embodiments of the present invention, node B refiises the LinkTeardownReq by 
not doing anything, i.e.. the node B does not send a message to node A indicating 
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that node B is refusing the request. By not sending a message, the load on the 
network will not be increased by sending messages for refusing a Link Teardown 
request. If, however, node B determines that Win (A) + Win (B) + WinNet is 
greater than or equal to zero ("Yes" path out of decision Step 1550) then node B 
5 accepts the LmkTeardownReq and sends a LinkTeardownAck message to node A 
(Step 1570). 

Figure 16B illustrates an exemplary LinkTeardownAck message in 
accordance with the present invention. The LinkTeardownAck message includes a 
From field indicating the source of the LinkTeardownAck, a To field indicatmg 

10 the destination of the LinkTeardownAck message and an Info field containing 
optional information, e.g., timing information. 

In accordance with the present invention, the sending of the 
LinkTeardownAck message triggers route maintenance procedures of the routing 
protocol such that the dhrect link between the source and destination nodes, i.e., 

15 the Imk To and From nodes, will be marked as unavailable. If the routing 

protocol finds an alternative path the LinkTeardownAck message can be sent on 
this alternative path. Otherwise, if the routing protocol fails to find an alternative 
path an error will result. In this case the LinkTeardownAck message is dropped 
and the link is logically restored as available to the network. If, however, an 

20 alternative path is found, when the LinkTeardownAck message arrives on the 
alternative path to the other end the link may be torndown. 

To avoid the link being logically marked as unavailable and then restored 
because of a dropped LinkTeardownAck message, the originator of the 
LinkTeardownReq message may trigger an alternative path discovery procedure 

25 before sending the message. Such a procedure may be part of the routing 

protocol, or it can be implemented as an addition to the routing protocol. As a 
result of the alternative path discovery, the node will not send the request when 
such an alternative path is not available. When such an alternative path is 
available, it can be possible to detennine the length of the alternative path. 
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HopCount. By sending the LinkTeardownReq message only when an alternative 
path has been found avoids the other end node unnecessarily marking the link as 
unavailable causing temporaiy disruptions on the trafBc flowing on the link. 
Further, knowledge of the alternative path can be used to estimate the load on the 
network that will be caused by tearing the link down, i.e. , WinNet. Using the 
HopCount, WmNet can be estunated using the formula WinNet =-2*(HopCount- 
l)*Tr, wherein Tr is the traffic on the link. 

If two or more Link Teardown attempts are being performed 
simultaneously, one Link Teardown procedure may teardown a link being used by 
other Link Teardown procedures. To avoid two or more Link Teardown attempts 
being performed simultaneously and periodically that would block alternative 
paths to each other. Link Teardown initiation should be performed at randomized 
time instants. 

In accordance with exemplary embodiments of the present mvention, since 
15 the Link Setup procedure uses a different table than the Link Teardown and the 
Master-Slave Switch procedures, the Link Setup procedure can be performed in 
parallel with the Link Teardown and the Master-Slave Switch procedures. 
Alternatively, Link Setop procedures can be performed serially with the Link 
Teardown and the Master-Slave Switch procedures. In addition, the present 
20 invention may be implemented such that a node mitially determiaes whether a link 
can be tomdown and if the Link Teardown procedures are unsuccessful then the 
node would initiate the Master-Slave Switch procedures. 

Now that the exemplary procedures of the present invention have been 
described, several examples wiU be presented to further illustrate the advantages 
of the present invention. Figures 17A through 17F iUustrate a pluraUty of nodes 
where a node which is an plication server is not the master of the piconet. The 
arrows illustrated in figures 17A through 17F indicate regular traffic flow between 
the nodes and not necessarily the messages used for the network reconfiguration 
procedures. Accordingly, Figure 17A iUustrates nodes A, B, C and D, where 
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node C is the master of the piconet while node A is an application server. Since 
node A is an application server, the nodes of the piconet, i.e., nodes B through D, 
will be requesting information from node A. However, since node C is the master 
of the piconet, all traffic from node A to nodes B and D must pass through node 
5 C. This results in an inefficient throughput of the piconet. By measuring the 
amount of traffic it is forwarding node C recognizes that the throughput of the 
piconet is inefficient and sends a LinkSetupSolicit message to node A. Node A 
then sends a LinkSetupReq message through node C to node B and node B 
acknowledges the setup of a link between nodes A and B by sending a 

10 LinkSetupAck message to node A through node C, Accordingly, a new link is 
setup between nodes A and B as illustrated in Figure 17B. 

Figure 17B illustrates the teardown of a link between nodes B and C. 
Initially, node B will send a LinkTeardownReq to node C requesting the teardown 
of die B-C link. In response, node C sends a LiokTeardownAck message 

IS acknowledging the teardown of the link between nodes B and C. Hence, the link 
between nodes B and C is torn down. 

Figure 17C illustrates a Lmk Setup between nodes A and D. The Link 
Setup is initiated by node C sending a LinkSetupSolicit message to node A. Node 
A responds with a LinkSetupReq message which is sent through node C to node 

20 D. Node D accepting the Link Setup sends a LinkSetupAck message through 
node C to node A acknowledging the setup of a link between nodes A and D. 

Figure 17D Dlustrates the teardown of the Hnk between nodes C and D. 
Initially, node D sends a LinkTeardownReq message to node C requesting to 
teardown the C-D lmk. Node C accepts the Link Teardown and sends a 

25 LnikTeardownAck message to node D acknowledging the teardown of the C-D 
link. 

Figure 17E illustrates the LinkMSSwitch between nodes A and C. As 
illustrated m Figure 17E, node A is a slave of the piconet comprising nodes A and 
C, and node A is the master of the piconet comprising nodes A, B and D. 
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Accordingly, node A sends node C a LinkMSSwitchReq message requesting to 
switch the master and slave roles between the two nodes. Node C acknowledges 
the Master-Slave Switch by sliding a LinkMSSwitchAck message back to node A. 

Figure 17F illustrates the network after it has been optimized by the above- 
described procedure. Node A which is an application server is now the master of 
the piconet comprising nodes A. B. C and D. Accordingly, the throughput of this 
piconet has now been increased by aUowing an application server to be the master 
of a piconet in which the nodes which are using the applications are slaves. 

Figures 18A through 18D illustrate another example of a plurality of nodes 
which switch from an inefficient network mto a more efBcient network using 
exemplary procedures of the present invention. The arrows illustrated in figures 
ISA through 18D indicate regular traffic flow between the nodes and not 
necessarily the messages used for the network reconfiguration procedures. In 
Figures ISA through 18D node A is an application server with nodes B through D 
as clients of the appUcation server. As illustrated in Figure 18A. node A, an 
application server, is a slave m a piconet comprising nodes A and B; a slave in a 
piconet comprising nodes A and C; and a slave in a piconet comprising nodes A 
and D. Smce an application server, node A, is a slave m three piconets. the 
network is very mefficient due to the overhead of node A switching from one 
piconet to another. Recognizmg this situation, node A sends a LinkMSSwitchReq 
message to node C requesting that node A become tiie master of the piconet 
comprising nodes A and C. Node C accepts flie Master-Slave Switch and sends a 
LinkMSSwitchAck message back to node A. 

Figure 18B Ulustrates that node A is now the master of the piconet 
comprising nodes A and C and a slave of the piconet comprismg nodes A and B 
and tiie piconet comprises nodes A and D. Accordingly, node A sends a 
LinkMSSwitchReq message to node D requesting tiiat node A become the master 
of the piconet comprising nodes A and D. Accepting the Master-Slave Switch, 
node D sends a LmkMSSwitchAck message back to node A. 
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Figure 18C Ulustrates that node A is now the master of the piconets 
comprising nodes A, C and D, and the master of the piconet comprising nodes A 
and D, and a slave m the piconet comprising nodes A and B. Node A mitiates a 
Master-Slave Switch by sending a LinkMSSwitchReq message to node B. Node B 
5 accepts the Master-Slave Switch and sends a LinkMSSwitchAck message back to 
node A. Accordingly, as illustrated in Figure 18D, an application server, node A, 
is the master of the piconet including nodes B through D, which results in a more 
efficient network configuration. 

Figures 19A through 191 illustrate a plurality of nodes which are initially 

10 connected as a string and eventually connected in a star configuration. The 

arrows illustrated in figures 19A through 191 indicate regular traffic flow between 
the nodes and not necessarily the messages used for the network reconfiguration 
procedures. Further, node A is an application server sending information to 
nodes B through F which act as clients. In Figure 19A, node B is the master of a 

15 piconet comprising nodes A, B and C; node D is the master of the piconet 

comprising nodes C, D and E; and node F is the master of a piconet comprising 
nodes F and E. Based upon the configuration illustrated in Figure 19A, node B 
requests that a Imk be setup between nodes A and C, node C requests that a link 
be setup between nodes B and D, and node E requests that a link be setup between 

20 nodes D and F. 

Figure 19B illustrates the results of the various Link Setups described in 
connection with Figure 19A. Accordingly, node B is the master of a piconet 
comprising nodes A, B, C and D; node C is the master of a piconet comprising 
nodes C and A; node D is the master of a piconet comprising nodes C, D, E and 

25 F; and node F is the master of a piconet comprising nodes E and F. Based upon 
the configuration illustrated in Figure 19B, C performs a Link Teardown with 
node B, D performs a Lmk Teardown with node B, and node E performs a Link 
Teardown with node F. 

Figure 19C illustrates the results of the various Lmk Teardowns described 



wo 02/25879 



PCT/SEOl/01681 



10 



-23- 

above in connection with Figure 19B. As illustrated in Figure 19C. node B is the 
master of a piconet comprising nodes A and B; node C is the master of a piconet 
comprising nodes A and C; and node D is the master of a piconet comprising 
nodes D, C, E and F. Based upon the configuration illustrated in Figure 19C, 
node C performs a Master-Slave Switch with node D and node A performs a 
Master-51ave Switch m± node B. 

Figure 19D illustrates the results of the Master-Slave Switches described 
above m connection with Figure 19C. As illustrated in Figure 19D. node A is the 
master of a piconet comprising nodes A and B; node C is the master of a piconet 
comprismg nodes A. C and D; and node D is the master of a piconet comprising 
nodes D, E and F. Based upon die configuration illustrated m Figure 19D. node 
C mitiates a Link Setup procedure between nodes A and D and node D mitiates a 
Link Setup procedure between nodes C and F. 

Figure 19E fllustrales die result of the above-described Lmk Setup 
procedures. As illustrated m Figure 19E. node A is die master of a piconet 
comprising nodes A. B and D; node C is die master of a piconet comprising nodes 
A. C. D and F; and node D is die master of a piconet comprising nodes D. E and 
F. Based upon die configuration iUustrated in Figure 19E. node D performs a 
Lmk Teardown procedure wifli node C and node F performs a Link Teardown 
20 procedure wifli node D. 

Figure 19F iUustrates the results of the Link Teardown procedures 
described above m connection widi Figure 19E. In Figure 19F. node A is die 
master of a piconet comprismg nodes A. B and D; node C is die master of a 
piconet comprising nodes A, C and F; and node D is die master of a piconet witii 
node E. Based upon die configuration illustrated m Figure 19F, node A initiates a 
Master-Slave Switch with node C. 

Figure 19G iUusd-ates die results of die Master-Slave Switch between 
nodes A and C described above in connection widi Figure 19F. As illustrated m 
Figure 19G. node A is die master of a piconet comprising nodes A, B, C and D; 
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node C is the master of a piconet comprising nodes C and F; and node D is the 
master of a piconet comprising nodes D and E. Based upon the configuration 
illustrated in Figure 19G, node C initiates a Link Setup procedure between nodes 
A and F and node D initiates a Link Setup procedure between nodes A and E. 
5 Figure 19H illustrates the results of the Link Setup procedures described 

above in connection with Figure 19G. As illustrated in Figure 19H, node A is the 
master of a piconet includmg nodes A, B, C, D, E and F; node C is the master of 
a piconet comprising nodes C and F; and node D is the master of a piconet 
comprising nodes D and E. Based upon the configuration illustrated in Figure 

10 19H, node F initiates a Link Teardown procedure with node C and node D 
initiates a Link Teardown procedure with node E. 

Figure 191 illustrates the result of the Link Teardown procedures described 
above in Figure 19H. As illustrated in Figure 191, node A, which is an 
application server, is now the master of a piconet comprising nodes A through F. 

15 Accordmgly, nodes B through F can now durectly request and access mformation 
stored on the application server A without having to send the request or receive 
the information through other nodes. 

It will be recognized that m certam situations using the above-described 
network reconfiguration procedures may not result in the most efficient 

20 configuration of the network being formed because an intermediate configuration 
results in worse performance than the original configuration. For example, 
referring now to figures 20A-20C, assume that the network configuration of 20C 
is more efficient than the network configurations of figures 20A and 20B. Further 
assume that the network configuration of figure 20A is more efficient than the 

25 network configuration of figure 20B. Since the network configuration illustrated 
in figure 20A is more efficient than the network configuration in figure 20B, the 
nodes will not perform a reconfiguration to the network configuration io figure 
20B, and hence, the more efficient network configuration of figure 20C will not 
be formed. In other words, since figure 20B has more links, the nodes may 
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mterprettbis as resulting in higher overhead. To address this situation the 
requirements for Link Sett,) conditions can be loosened. For example inore 
optimistic. i.e.. smaUer. values for the overhead of establishing a new link when 

computingtheWinvaluesintheLinkSetupprocedurecanbeused. Ifthesmaller 
vah.es of the overhead for establishing a new link are used a longer interval for 
Pao™ should be used to avoid instability which would result from setting up a new 
link that has been recently torn down. 

Although the present invention has been described using a constant thne 
penod for a node to initiate reconfiguration attempts, a node could set the time 
between sending two reconfiguration attempt messages based on the amomat of 
traffic that would be affected by the reconfiguration. Accordingly a 
reconfiguration which affects a lot of traffic will likely be performed earlier than 
another reconfiguration which affects less traffic. Adjusting the time between 
reconfigmration atten^ts can be useful when a nmnber of nodes perform 
reconfiguration attempts simultaneously and these reconfiguration attempts 
exclude each other. For example, iftwo nodes independently initiate a new Link 
Setup, where one of the node is forwarding 50kbps of information and the other 
node is forwarding 200kbps of information. When the two Link Setups exclude 
each other, i.e.. one of the Lmk Setup will not be performed as soon as die odaer 
Lmk Setup is performed, then it is beneficial if the one fonvarding the less amount 
of traffic waits a longer time before initiation than the other, m this way it is 
more likely that a reconfiguration U^at affects more traffic will be the one to be 
carried out. 

Although in the procedures above, a reconfiguration attempt would not be 
performed if the expected capacity change is negative, i.e.. flxere will be less 
capacity after the reconfiguration than before, in certain situations it may be 
advantageous to aUow these reconfiguration tooccur.. For example, by taking into 
account the amount of free capacity that a node has. a node which has a large 
amount of free resom-ces can accept a reconfiguration attempt which implies a 
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higher amount of overhead because this does not reduce the network capacity if 
more overhead is unposed on nodes that have free capacity. Further, network 
capacity can be improved if a reconjSguration decreases the overhead at 
overloaded nodes even at the cost of imposing more overhead on nodes with free 
5 capacity. 

Furttier, although the present invention has been described as using two 
separate tables, i.e., a Traffic Forwarding Table and a Neighbor Traffic Table, to 
make reconfiguration decisions, it will be recognized that these tables can be 
combined into one table. 

10 The present invention has been described with reference to several 

exemplary embodiments. However, it will be readily apparent to those skilled in 
the art that it is possible to embody the invention m specific forms other than those 
of the exemplary embodiments described above. This may be done without 
departing from the spirit of the mvention. These exemplary embodiments are 

15 merely illustrative and should not be considered restrictive in any way. The scope 
of the invention is given by the appended claims, rather than the preceding 
description, and all variations and equivalents which fell within the range of the 
claims are intended to be embraced therein. 



wo 02/25879 



PCT/SEOl/01681 



10 



-27- 

WHAT IS CLAIMED IS: 

1. In an ad-hoc network a method for reconfiguring the network 
conprising the steps of: 

determining whether a predetermined time period has expired; 
examining a table if the predetermined time period has expired; and 
selectively initiating a link setup procedure, a role switch procedure or a 
link teardown procedure based upon information in the first or second table. 

wherein the Imk senip procedure is mitiated by a node which forwards 
trafBc between two end nodes, and the role switch procedure and the link 
teardown procedure are initiated by an end node. 

2. The method of clafan 1. wherein the first table contains mformation 
about traffic that a node is forwarding and the second table contams infonnation 
about trafSc of neighboring nodes. 

3. The niethodofclaiml. Wherein the link setup procedure comprises 
15 thestq)sof: 

sending a link setup solicit message to a first end node; 

sendmg a link setup request message fi-om the first end' node to a second 
end node; and 

responding with a Imk setup acknowledgment message from the second 
20 end node if the second end node accepts the link setup. 

4. The method of claim 3. wherein the second node accepts the link 
setup based upon whether the link to be setup increases the capacity of the 



network. 



5. 



The method of claim 1. wherein the Imk role switch procedure 
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comprises the steps of: 

sending a link role switch request message from a first end node to a 
second end node; and 

responding with a link role switch acknowledgment message from the 
5 second node to the first node if the second node accepts the role switch. 

6. The method of claim 5, wherein the second node accepts the role 
switch if the role switch increases the network capacity or if the network capacity 
is unchanged by the role switch, the second node accepts the role switch if the 
first node has a higher traffic activity than the second node. 

7. The method of claim 1, wherein the link teardown procedure 
comprises the st^s of: 

sending a link teardown request message from a first node to a second 
node; and 

responding with a link teardown acknowledgment message from the second 
node to the first node if the second node accepts the link teardown request. 

8. The method of claim 7, wherein the second node accepts the link 
teardown request based upon the sum of capacity increase at the first and second 
nodes as well as a capacity change in the network due to rerouting of traffic from 
the torn down link. 

20 9. The method of claim 1 , wherein the network operates in accordance 

with Bluetootii protocol. 

10. The method of claim 1 , wherein the network is a wireless network. 

1 1 . The method of claim 7, wherein the link teardown procedure 



10 



15 
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fiirther comprises the steps of: 

triggering a route maintenance procedure to find an alternative path 
between the first node and the second node; and 

sendmg the link teardovm acknowledgment message over the alternative 

5 path. 



10 



15 



20 



12. The method of claim 7. wherein the link teardown procedure 
fiirther comprises the steps of: 

triggering a route maintenance procedure at the first node to find an 
alternative path prior to sending the link teardown request message; and 

sending the link teardown request message to the second node if the an 
alternative path is found. 



13. The method of claim 1. wherein the predetermined time period is 
set based upon an amount of trafBc that would be affected by the reconfiguration. 

14. The method of claim 1. wherein if the link setup procedure, role 
switch procedure or the link teardown procedure fails, performing the step of: 

setting a backoff timer to a minimmn value between two times a current 
vahie of the backoff timer and a maximum backoff timer value. 

15. A network comprising: 
a first node including a first table; 
a second node including a second table; and 

a first communications link connecting the first node and the second node, 
wherein the first node periodicaUy determines whether to initiate 
reconfiguration of the network based upon information stored in flie first table and 
the second node periodically determines whether to initiate reconfiguration of the 
25 network based upon information stored in the second table. 
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16. The network of claim 15, further comprising: 
a third node coni^rising a third table; and 

a second communications link connecting the third node to the second 

node, 

S wherein the third node periodically determines whether to initiate 

reconfiguration of the network based upon information stored in the third table. 

17. The network of claim 16, wherein the second node periodicaUy 
determines, based upon an amount of traffic forwarded by the second node 
between the first and third nodes, whether to initiate a link setup procedure 

10 between the first and third nodes. 



18. The network of claim 17, wherein the link configuration procedure 
establishes a third communications link between the first node and the third node. 

19. The network of claim 15, wherein the first node, based upon an 
amount of traffic handled by the first node and an amount of capacity that the first 

15 node estimates it will be able to gain by a master-slave switch, initiates a master- 
slave switch procedure with the second node. 



20. The network of claim 15, wherein the first node, based upon an 
amount of capacity that the first node estimates it will be able to gain as the result 
of a link teardown and based upon an amount of capacity that the network will 
20 gain as a result of the link teardown, initiates a link teardown procedure with the 
second node. 



21. The network of claim 15, wherein first table contains information 
about traffic that the first node is forwarding and information about traffic to and 
from nodes which are neighbors of the first node, and the second table contains 
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mfonnation about traffic that the second node is forwarding and information about 
traffic to and from nodes which are neighbors of the second node. 
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